Updated and closed the bug report. Best regards to the development team!!! :) I guess the issue will not be resolved for Catalina, will it?

Today I updated to macOS 11 Big Sur Beta and tried to reproduce the issue. I could NOT reproduce the issue. Does that mean that apple has already fixed the issue for Big Sur or NetworkExtension in Big Sur did not suffer from that problem from the very beginning!? The last version of macOS where the issue repoduces is 10.15.6

Hi! Ay updates on the subject?

Thanks for approval, meaton. I have submitted a bug report. Its ID is FB7868606

Thank you, meaton  if you take the App Proxy Provider out of the equation and test this with the browser do you see the same results? With NEAppProxyProvider disabled browser works as it should work - without any connection interruption. That's one of the reasons why I considered the NEAppProxyTCPFlow to be the cause of the issue. Make sure that if you open a bug that you include your packet traces that you have taken along with any logs. Ok, I'll try to assemble as much details about the issue as I can. Alas, I cannot capture packets between source app and NEAppProxyTCPFlow via WireShark to see the difference in packets between enabled NEAppProxyProvider and disabled, only packets from NWConnection from proxying side are shown to me. I guess only developers of the NEAppProxyProvider can get to the bottom of the problem :) And one more question. Should I attach a link to this thread to the bug report?

Should I submit a bug report?

Thank you for the answer, meaton! I've already enabled enableKeepalive in NWProtocolTCP.Options() along with noDelay, but it isn't an issue because the termination of the connection is caused by the source app's side. I've been experimenting for a few weeks with different approaches and analyzing network communication via WireShark. And my conclusion is: the bug is in the NEAppProxyTCPFlow because the source app behaves like it doesn't receive keep-alive approvement from the NEAppProxyTCPFlow even though it receives data. I tried to just call NEAppProxyFlow.open() and NOT writing any data to it - the result is the same, browser waits for 45 second and forcibly closes the connection with net::ERRTIMEDOUT, the same behavior as when I transmit data to the source app via NEAppProxyFlow.write(). This issue relates to all Chromium browser. As I said, Safari works fine, but I assume the reason of it is because Safari uses different approach of keeping sockets alive.

correction: safari works fine, connection doesn't interrupt. Chrome still forcibly closes a connection after 45 sec and Firefox after 11 min 22 sec with error net::ERRTIMEDOUT

Months of surfing and exploring information about apps traffic interception leveraging network extension I assume your choice is NEAppProxyProvider. But you would have to use apple's APIs anyway and adapt your cross-platform solution for it.